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Parametric cost analysis uses equations to map measurable system attributes into cost. The 
measures of the system attributes are called metrics. The equations are called cost 
estimating relationships (CER's), and are obtained by the analysis of cost and technical 
metric data of products analogous to those to be estimated. Examples of system metrics 
include mass, power, failure_rate, mean_time_to_repair, ener gy consumed, 
payload_to_orbit, pointing_accuracy, manufacturing_complexity, number_of_fasteners, 
and percent_of_electronics_weight. 

The basic assumption is that a measurable relationship exists between system attributes 
and the cost of the system. If a function exists, the attributes are cost drivers. Candidates 
for metrics include system requirement metrics and engineering process metrics. 
Requirements are constraints on the engineering process. From optimization theory we 
know that any active constraint generates cost by not permitting full optimization of the 
objective. Thus, requirements are cost drivers. Engineering processes reflect a projection 
of the requirements onto the corporate culture, engineering technology, and system 
technology. Engineering processes are an indirect measure of the requirements and, hence, 
are cost drivers. 

Many metrics are obvious. Mass and lines_of_code are measures of unit production 
effort. Number_of_production_units and number_of_prototypes are measures of program 
size. Technology is a function of time, so its effects may be measured through changes 
with time. For expendable launch vehicles the mass of the tankage is proportional to the 
tank volume. Thus tank _volume, energy _consumed, and fuel_energy _density are 
functionally related to mass, a measure of production effort. Other metrics are not so 
obvious. 

Parametric analysis normalizes for the effect of metrics x^. 
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is a commonly used CER with associated linear form 
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used with least squares to obtain the coefficients a^. 

The exponential factors do an excellent job of normalizing cost for temporal effects 
such as inflation, technology escalation, and for binary categories and other abstract 
metrics. The power law factors do an excellent job of normalizing cost for economic 
quantities such as number_of_ production_units, lines_of_code, number_of _prototypes, 
kilograms_per_production_unit, and so on. The hybrid combination of these factors 
usually improves accuracy over the use of either separately. If we pre-normalize the data 
for inflation using an inflation table and define 
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expresses cost in a form in which technology escalation and the more abstract quantities 
adjust the unit economic quantity case up and down to establish the origin for the 
unnormalized economic quantities as in Figure 1. If x^ = time then q is a measure of 
system complexity which includes the additive temporal effect of technology measured by 

ai x l- 

This definition of system complexity is convenient since it is linear in its components. 
The component aq represents complexity arising from as yet undetermined complexity 
drivers. With a] measuring technology escalation, the remaining components could be 
chosen to represent binary characteristics of the system, such as whether the unit was to be 
used in a manned or unmanned spacecraft or whether recent software engineering 
techniques were used to develop the software. 
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FIGURE 1 : COMPLEXITY AND ECONOMY OF SCALE 



This form also permits a simple relative analysis of cost for specific cost drivers. 
Suppose two systems had identical metric values except for MTBF = 
mean_time_between_failure. All other metrics being equal, either 


r m = ea m (MTBF 1 -MTBF 2 ) 


or 


/MTBF] xa m 
r m - (mtBF 2 J ’ 


whichever provides the least root_mean_square 

_error over the data base, measures the relative cost factor due to reliability as measured by 


MTBF. 
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The property of normalization, in effect, increases the data base of the parametric 
analyst. When unofficially first asked how much the National Aerospace Plane would 
cost, I used this process to qualify a BIB bomber for the manned space environment and 
project it's technology to the initiation of operational capability. Within a half hour I had an 
unofficial estimate. I recently saw an estimate for a Mars rover vehicle which manned 
space qualified an army vehicle and projected its technology to the Mars landing date. 


RISK ANALYSIS 

When asked some years ago by a project manager to provide the exact cost of a project 
just beginning the conceptual design phase, I replied that I would do so if the project 
manager would first supply me an exact labor, material, and rate scenario over time which 
represented the final product configuration. The fact is, there is no single cost for a system 
until after completion. In all cases prior to completion, a range and distribution of final cost 
exists which corresponds to the many possible projects resulting from future decisions. 

Dean, et al, 1986, developed a simple procedure for analyzing cost risk which is used 
extensively at the NASA Langley Research Center (LaRC). The premise is that the 
distribution of possible costs is defined by future project decisions. Although these 
decisions are not yet known, they are represented by best case, perceived case, and worst 
case parametric engineering process and configuration assumptions. For each work 
breakdown structure (WBS) element, the costs are derived by parametric analysis from the 
assumptions for that case. A program receives as inputs the three case costs from the 
output of three independent parametric cost estimates. Each of several hundred passes 
through this data provides a possible cost consisting of the sum of the possible costs for 
each element. The cost for each element is selected randomly from one of the three case 
costs for that element. The result is an approximation of the distribution of possible costs 
covering the cost range from very best case to very worst case. 

Results are presented to management in the form of this distribution of possible costs with 
an expected value. The typical skew of this distribution toward the worst case cost 
provides an expected value which is usually considerably higher than the perceived cost. 
This phenomenon has also been observed by Mazzini, R.A., 1986. The expected value 
represents the net risk considering that some tasks will cost less than perceived and some 
more than perceived. The typically observed ratio of the expected cost to perceived cost for 
a project is about the same ratio as the average NASA cost overrun based on actuals. 


THE COST ESTIMATING PROCESS 

There is a fundamental process which underlies any cost estimate to provide the basis 
for credibility. 

First, the estimator must understand the system to be estimated. What functions must 
the system perform? What are the operations and support requirements? What are the 
environmental requirements of the system? What are the major subsystems? What 
technologies are employed by each subsystem and assembly? What are the system and 
subsystem reliability, maintainability, availability, and safety requirements? 

Next, the estimator must understand the programmatics of the system to be estimated. 
When is development supposed to begin? When is the first production article to be 
completed? How many prototypes, test articles, production items, and spares will there 
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be? When is the envisioned initial operating capability? What and when are the system 
review points? 


Next, the estimator must establish the system estimating work breakdown structure 
(WBS). What are the system deliverables? At what level of the WBS are items found for 
which comparable cost data are available? 

Next, the estimator must obtain comparable or analogous cost data for each WBS 
element at which cost is estimated and normalize for known differences such as material, 
quantity, quality, operational environment, or performance. 

Next, the estimator must interview project personnel to obtain system parameters and 
risk factors. How much design has already been accomplished? What are the materials 
and their relative percentages? What is the percentage of electronics by weight? How 
much is each subsystem pushing the state-of-the-art? What could possibly go wrong in 
design, test and evaluation, production, operations, and support? 

Next, the estimator must perform a technology projection. What will the technology 
candidates be for each subsystem at design freeze? What technology is most likely to be 
used? What are the potential cost effects of each of the candidate technologies? If 
technology candidates are unspecified, what is the rate of cost escalation for comparable 
past technologies? 

Next, the estimator must obtain feedback from project personnel on the validity of 
system parameters used to build the cost model. Did I understand correctly that you said 
...? Is ... technology really a candidate for the ... subsystem? Is ... really a safety risk? 

Next, the estimator must iteratively generate cost estimates from system parameters 
until all input parameters are representative of the project as perceived by the project and 
estimating personnel. 

Next, the estimator must perform a risk analysis which should indicate a measure of 
cost risk based upon the degree of engineering definition available. What are the relatively 
high risk subsystems? What are the reasons for that risk? 

Next, the estimator must undergo a systematic peer review. Does the model and its 
inputs properly describe the system? Have the model results been properly reported? 

Next, the estimator must document the cost estimate, the cost model, the cost model 
inputs, the cost model outputs, and the supporting analysis. What is the distribution of 
possible project costs? What models and modeling techniques were used? What are the 
project assumptions for the best, perceived, and worst cases for the risk analysis? 

Finally, the results must be presented to the proper authorities and successfully 
defended . 


THE ESTIMATING ENVIRONMENT 

At NASA LaRC, the Vehicle Analysis Branch (VAB) has the responsibility for 
analyzing future space transportation systems. The Cost Estimating Office (CEO), among 
other duties, estimates the cost of each VAB configuration. One or more members of the 
CEO is a member of each conceptual design team. The VAB team members generate the 
configuration and, in interview with the CEO, provide the technical system metrics required 
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by the CEO. The CEO generates the cost estimate and, in interview with the VAB, 
provides an expected cost, an optimum schedule, a cost risk distribution, and an analysis of 
the cost drivers. A very important feedback loop between cost and configuration now 
exists which permits the VAB to alter configurations based upon an analysis of cost and 
schedule. 

An early realization that the cost estimating tools and techniques were inadequate to 
provide requested information led to a very important quest for understanding. As is 
always true for large budget products, it is very important to have a credible project cost 
estimate. However, with the cost/configuration loop, it became equally important to have a 
credible understanding of why the project costs that much and how it might be reconfigured 
to save cost. That was the information being requested! A large mental, cost technology, 
and technical leap was required between estimating "the cost" and participating as an 
integral member of a highly qualified advanced space transportation system design team. 

NASA has developed a scale of technology readiness which is defined as follows: 

Level 0: Basic principles not yet observed or reported. 

Level 1: Basic principles observed and reported. 

Level 2: Conceptual design formulated. 

Level 3: Conceptual design tested analytically or experimentally. 

Level 4: Critical function/characteristic demonstration. 

Level 5: Component/breadboard tested in relevant environment. 

Level 6: Prototype/engineering model tested in relevant environment. 

Level 7: Engineering model tested in space. 

Level 8: Lull operational capability. 

Because it is closely related to engineering difficulty, it is exceptionally useful for 
discussing and quantifying technology readiness. 

Since the proposed initial_operating_capability _date for NASA systems being studied 
at LaRC ranges from as early as 1995 to beyond 2030, the proposed configurations contain 
much technology that is highly immature. Some structural technology borders on being 
made with "unobtainium," a level 0 material, with an occasional level 8 Shuttle type 
construction. The control technology ranges between levels 2 and 4. The propulsion is 
between levels 2 and 8. The software ranges between levels 1 and 4. The system health 
monitoring ranges between levels 1 and 4. The operations and support range between 
levels 1 and 8. Naturally, the further out the projected initial_operating_capability_date, the 
lower the technology level index. 

The wide range of technology choices yet to be made is the major cost risk driver in all of 
these studies. This often results in a wide range of technical metric values between the best 
and worst cases. The cost uncertainty index 
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_ worst_case_cost 
- best_case_cost 


is an indicator of engineering definition maturity. The second major cost risk driver is the 
uncertainty associated with the calibration data. 

For the projects discussed in this paper the primary hardware development and 
production estimating model was PRICE H (Anon., 1988a). The primary software 
estimating model was PRICE S (Anon., 1988b). The life cycle and risk analysis models 
were developed by the CEO. Various NASA and Air Force models were used for 
calibration. 


ENTRY RESEARCH VEHICLE 

The Entry Research Vehicle (ERV), shown in Figure 2, was proposed as an experiment 
to be carried into space in the Shuttle payload bay, released in orbit, deorbited, and reenter 
the atmosphere. Virtually each component of the spacecraft was an experiment to test some 
new material or concept. The nosecap was a liquid heat pipe which, because of its conical 
shape, was deemed by some to be impossible to develop, i.e., level 0 technology. With 
the exception of a level 8 propulsion system adopted from Shuttle, most other technologies 
were between levels 1 and 4. 

FIGURE 2: THE ENTRY RESEARCH VEHICLE 


Gross dry 
weight 




Because it was the first major estimate for the estimator who had no previous aerospace 
background, a considerable amount of time was spent in understanding the system and 
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learning the tools and techniques required to perform this estimate. The VAB arranged 
special meetings with the primary purpose of educating CEO personnel. Additional time 
was spent developing and fine tuning the LaRC estimating process. This estimate, see 
Moore, A.M., Bogart, E.H., and Dean, E.B., 1987, produced two major outputs: a 
credible cost estimate for ERV and, even more important, a credible estimating process for 
LaRC. 

The cost estimate, including cost risk, was successfully presented to NASA 
Headquarters by the estimator. 


CREW EMERGENCY RETURN VEHICLE 

The Crew Emergency Return Vehicle (CERV) is shown in Figure 3. CERV is a space 
vehicle which remains attached to the space station Freedom to provide emergency return of 
astronauts to Earth. Three configurations have been in competition, a ballistic capsule 
sponsored by the Johnson Space Center (JSC), an Apollo-like capsule sponsored by JSC, 
and a lifting body sponsored by LaRC. 

The CERV Project Office at JSC requested a workshop to compare the three vehicles 
from both a technical and cost viewpoint. Nine different requirements were established and 
each vehicle was designed to meet those requirements. Requirements one through three 
were combined to generate another configuration for comparison. A water landing version 
called the Assured Crew Return Craft (ACRC) was also established to make a direct 
comparison between lifting body and non-lifting body technologies by removing the 
runway landing variable associated with the lifting body. 

FIGURE 3: THE CREW EMERGENCY RETURN VEHICLE 
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Over a two month period, each configuration was designed and costed. The cost risk 
distributions were overlaid as in Figure 4. Clearly, the risk of the project itself was 
dominant over the risk inherent in any single configuration. With the exception of two 
configurations, the configuration choice should be made on requirements, not cost. 

FIGURE 4: CERV COST RISK FAMILY 
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The workshop at JSC consisted of sessions to reconcile technical and cost 
assumptions. From the cost viewpoint, it was recognized early that the LaRC and JSC cost 
estimating methodologies were extremely different and most of the workshop was spent 
reconciling those differences. Since JSC did not perform a risk analysis, considerable time 
was spent removing risk to provide a single point perceived estimate for comparison. At 
the conclusion, all agreed that the lifting body was only slightly more costly than the other 
versions. However, since one of the parties had not performed a risk analysis, that 
decision was made without the extra perception provided by risk. 

After the workshop the resolution of the tradeoffs was left to CERV and NASA 
management. Whatever the final decision, cost has played an important role in the design 
and decision process. 


ADVANCED MANNED LAUNCH SYSTEM 

Recent configurations of the Advanced Manned Launch System (AMLS) are shown in 
Figure 5. The AMLS is a high priority manned vehicle for satellite servicing and up- 
payload/down-payload to and from space station Freedom. At the NASA steering 
committee kickoff meeting a viewgraph stated that "Cost is a key design parameter." The 
Chair's prompt restatement was that "Cost is the key design parameter." 
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FIGURE 5: THE ADVANCED MANNED LAUNCH SYSTEM 
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technology for technology's sake. Examine the economic effects of each major design 
issue. Increase tolerances as much as possible. Reduce the number of pieces. Do not 
trade structure for relatively expensive electronics. For low production items, do not trade 
the economy of scale of hardware for the dis-economy of scale of software. Buy spares, 
don't cannibalize. Relax performance requirements. Do whatever is necessary to 
economically increase system reliability and quality. In general, avoid complexity. 

After a number of tradeoffs of different vehicles to place the same payload in orbit over 
time, it became evident that the cost did not seem to vary greatly even though substantially 
different technologies were used. A graph demonstrated that for each technology there was 
a minimum vehicle dry mass required to place a zero payload in orbit. This graph also 
demonstrated that the vehicle dry mass was a linear function of payload mass. Repeated 
observations led to the hypothesis that the energy required to obtain orbit was the primary 
cost driver. Also the architecture of the system, i.e., how the overall system is structured, 
is a large but secondary cost driver. The technology differences fine-tuned the energy 
dominated complexity. The very humbling current hypothesis is that the energy demands 
to accomplish the task fix the technology levels and the system structure so that we have 
some, but only slight, capability to adjust and still meet requirements. 

The more leisurely period of assessing progress has come and gone again with the 
renewed analysis of additional configurations. The design team recently designed, sized, 
and estimated the cost of an expendable rocket launch vehicle with a return glider, a 
partially reusable rocket powered vehicle with an expendable core and a reusable 
propulsion/avionics module, and a fully reusable two stage rocket powered vehicle; each at 
four different payloads. The cost estimates and subsequent analysis provided surprising 
and sometimes counterintuitive results. 

The lessons learned on the last round of configurations are currently being applied by 
the design team to a number of new configurations. The design and sizing of the new 
configurations is in process. The search has been renewed for cost and related technical 
data for more specific system functions, hopefully, to provide a better cost estimate and 
analysis for the new configurations. The design process continues for both the technical 
and cost members of the design team. 
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